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APPEAL BRIEF 
UNDER 37 C.F.R. § 41.37 

Appeal is taken from the Examiner's Office Action mailed April 12, 2005 finally 
rejecting claims 7, 9, 1 1, 15, 18-20, 22, 26-27, and 29-41 in this application. 
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I. REAL PARTY IN INTEREST 
37 C.F.R. §41.37(c)(l)(i) 

Novell, Inc. is the real party in interest. 

II. RELATED APPEALS AND INTERFERENCES 
37 C.F.R. § 41.37(c)(l)(ii) 

There are no other appeals or interferences known to Appellant, the Appellant's 
representative, or assignee that will directly affect or be directly affected by or have a bearing 
on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 
37 C.F.R. § 41.37(c)(l)(iii) 

Status of all of the claims: 

1. Claims presented: 1-41 

2. Claims withdrawn from consideration but not cancelled: NONE 

3. Claims canceled: 1-6, 8, 10, 12-14, 16-17, 21, 23-25, and 28 

4. Claims pending: 7, 9, 1 1, 15, 18-20, 22, 26-27, and 29-41 of which: 

a. Claims allowed: NONE 

b. Claims rejected: 7, 9, 1 1, 15, 18-20, 22, 26-27, and 29-41 

All the rejected claims, namely claims 7, 9, 1 1, 15, 18-20, 22, 26-27, and 29-41, are 
being appealed. The appealed claims are eligible for appeal, having been finally rejected. 

IV. STATUS OF AMENDMENTS 
37 C.F.R. § 41,37(c)(l)(iv) 

This patent application was filed on December 22, 1999. On December 4, 2002, the 
Examiner issued an Office Action rejecting claim 15 under 35 U.S.C. § 1 12, ^ 2 as having 
insufficient antecedent basis, rejecting claims 1-6 and 15-22 as originally filed under 
35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to Meltzer et al. in 
view of U.S. Patent No. 6,101,541 to Ellesson et al., and rejecting claims 7-14 as originally 
filed under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to 
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Meltzer et al. in view of U.S. Patent No. 6,101,541 to Ellesson et al. and U.S. Patent No. 
6,012,098 to Bayeh et al. On February 28, 2003, Appellant responded by amending claims 7, 
9, 13, and 15, cancelling claim 8, indicating that the amendment to claim 15 overcame the 
rejection under 35 U.S.C. § 1 12, U 2, and arguing against the rejections based on Meltzer in 
view of Ellesson, with and without Bayeh. 

On May 5, 2003, the Examiner issued a Final Office Action, rejecting claims 1-6 and 
15-22 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to 
Meltzer et al. in view of U.S. Patent No. 6,101,541 to Ellesson et al., and rejecting claims 7 
and 9-14 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to 
Meltzer et al. in view of U.S. Patent No. 6,101,541 to Ellesson et al. and U.S. Patent No. 
6,012,098 to Bayeh et al. On June 23, 2003, Appellant responded with an Amendment After 
Final, amending claims 7, 9-11, 13, 15, 18-20, and 22, cancelling claims 1-6, 12, 14, 16-17, 
and 21, and arguing against the rejections over Meltzer in view of Ellesson, with and without 
Bayeh. On July 7, 2003, the Examiner issued an Advisory Action, refusing to enter the 
amendment on the grounds that it raised new issues that would require further consideration 
and/or search, and was not deemed to place the application in better form for appeal. On 
August 5, 2003, Appellant filed a Request for Continued Examination, requesting 
consideration of the amendment submitted on June 23, 2003, and submitted a further 
amendment amending claims 18 and 22 and adding new claims 23-25. 

On October 3, 2003, the Examiner issued a third Office Action, rejecting claims 7, 9- 
10, 18, and 22 under 35 U.S.C. § 1 12, U 2 as being indefinite for failing to particularly point 
out and distinctly claim the subject matter which Appellant regarded as the invention, 
rejecting claims 15, 18-20, and 22 under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 6,125,391 to Meltzer et al. in view of U.S. Patent No. 6,101,541 to Ellesson et al., 
and rejecting claims 7, 9-1 1, and 13 under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent No. 6,125,391 to Meltzer et al. in view of U.S. Patent No. 6,101,541 to Ellesson 
et al. and "Official Notice". On December 12, 2003, Appellant's attorney held an interview 
with the Examiner to discuss the references, but no agreement was reached. On December 
23, 2003, Appellant responded by amending claims 7, 9-10, 15,18, and 23, and arguing 
against the rejections over Meltzer in view of Ellesson, with and without "Official Notice". 

On March 15, 2004, the Examiner issued a second Final Office Action, rejecting 
claim 7 under 35 U.S.C. § 1 12, K 2 as indefinite for failing to particularly point out and 
distinctly claim the subject matter which Appellant regarded as the invention, rejecting 
claims 15, 18-20, and 22 under 35 U.S.C. § 103(a) as unpatentable over U.S. Patent No. 
6,125,391 to Meltzer et al. in view of U.S. Patent No. 6,622,170 to Harrison et al., and 
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rejecting claims 7, 9-11, and 13 under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 6,125,391 to Meltzer et al. in view of U.S. Patent No. 6,622,170 to Harrison et al. 
and "Official Notice". On June 14, 2004, Appellant filed a Request for Continued 
Examination, amending claims 7, 11, 15, 18, 20, and 22, cancelling claims 10, 13, and 23-25, 
adding new claims 26-41, and arguing against the rejection over Meltzer in view of Harrison, 
with and without "Official Notice". 

On August 24, 2004, the Examiner issued a fifth Office Action, rejecting claim 27 
under 35 U.S.C. § 1 12, Tf 1 as failing to comply with the written description requirement, 
rejecting claims 7, 9, 1 1, 26-28, and 36 under 35 U.S.C. § 1 12, If 2 as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which Appellant 
regards as the invention, rejecting claims 7, 9, 11, 15, 26-28, and 32-41 under 35 U.S.C. 
§ 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to Meltzer et al. in view of 
U.S. Patent No. 6,772,396 to Cronin et al., and rejecting claims 18-20, 22, and 29-31 under 
35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to Meltzer et al. in 
view of U.S. Patent No. 6,772,396 to Cronin et al. and U.S. Patent No. 6,622,170 to Harrison 
et al. On November 4, 2004, Appellant responded by amending claims 7, 15, 26, 32, 36, and 
39-40, cancelling claim 28, and arguing against the rejection over Meltzer in view of Cronin, 
with and without Harrison. 

On February 4, 2005, Appellant's attorney held an interview with the Examiner. 
Agreement was reached regarding clarifying the term "event" as used in the claims. 
Although Meltzer was also discussed, no agreement was reached regarding what Meltzer 
taught. On February 8, 2005, Appellant amended claims 7, 15, 18, 32, and 40 consistent with 
the interview of February 4, 2005. 

On April 12, 2005, the Examiner issued a third Final Office Action, rejecting claims 
7, 9, 1 1, 15, 26-27, and 32-41 under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 6,125,391 to Meltzer et al. in view of U.S. Patent No. 6,772,396 to Cronin et al. 
and Heskett ("An XML standard for directory services"), and rejecting claims 18-20, 22, and 
29-31 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,125,391 to 
Meltzer et al. in view of U.S. Patent No. 6,772,396 to Cronin et al., Heskett ("An XML 
standard for directory services"), and U.S. Patent No. 6,622,170 to Harrison et al. On July 
12, 2005, Appellant responded by arguing against the rejection over Meltzer in view of 
Cronin and Heskett, with and without Harrison. 

On July 27, 2005, the Examiner issued an Advisory Action, disagreeing with 
Appellant's arguments. 
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V, SUMMARY OF THE CLAIMED SUBJECT MATTER 
37 C.F.R. § 41.37(c)(l)(v) 

A software program for facilitating the use of a distributed directory running in a 
computer network is claimed by exemplary independent claim 7. The program receives an 
event representing a change to the distributed directory into an XML generator. The event is 
converted to XML data. The XML data is then transformed using stylesheets into 
predetermined formats and transmitted to applications that can use the transformed formats. 

A software program for facilitating the use of a distributed directory running in a 
computer network is claimed by exemplary independent claim 15. The program receives a 
first event representing a change to the distributed directory from a first application. The first 
event is converted to a markup language data, and thence transformed to a predetermined 
format. The transformed first event is then transmitted to the distributed directory. A second 
event received from a second application is similarly converted into markup language data 
and transformed to the predetermined format before it, too, is transmitted to the distributed 
directory. 

A distributed computer system is claimed by exemplary claim 18. Processors 
connected to the network have connected memory, and can store portions of a distributed 
directory. Applications can also be stored in the memories. Transformation profiles specify 
predetermined formats for the applications. Software can detect an event representing a 
change to the distributed directory. Software can then transform the event into the 
predetermined formats and provide the transformed events to the applications. 

A method for interfacing with a distributed directory in a computing system is 
claimed by exemplary independent claim 32. The method involves two applications 
providing a transformation profiles defining a predetermined formats for use by the 
applications. When an event, such as a change to a distributed directory, is detected, the 
event is transformed to the predetermined formats using a transformation tool and the 
transformation profiles. The transformed event is then provided to the applications. 

A driver infrastructure for interfacing a distributed directory and applications is 
claimed by exemplary claim 40. A generator can receive an event representing a change to 
the distributed directory. A transformation processor can use transformation profiles to 
transform the event into predetermined formats that can be used by applications. A 
transmitter can then transmit the transformed events to the applications. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

37 C.F.R. § 41.37(c)(l)(vi) 

Claims 7, 9, 11, 15, 26-27, and 32-41 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Patent No. 6,125,391 to Meltzer et al. ("Meltzer") in view of 
U.S. Patent No. 6,772,396 to Cronin et al. ("Cronin") and Heskett ("An XML standard for 
directory services"). Claims 18-20, 22, and 29-31 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Meltzer in view of Cronin, Heskett, and U.S. Patent No. 6,622,170 to 
Harrison et al. ("Harrison"). 

For the convenience of the Board of Appeals, the entire Office Action dated 
December 4, 2002, the entire Final Office Action dated May 5, 2003, the entire Office Action 
dated October 3, 2003, the entire Final Office Action dated March 15, 2004, the entire Office 
Action dated August 24, 2004, the entire Final Office Action dated April 12, 2005, and the 
entire Advisory Action dated July 27, 2005 have been reproduced and attached as Exhibits 1- 
7, respectively. 

The grounds of rejection to be reviewed by the Board of Appeals are the rejections 
under 35 U.S.C. § 103(a) over Meltzer in view of Cronin and Heskett, and over Meltzer in 
view of Cronin, Heskett, and Harrison. 

VII. GROUPING OF CLAIMS 

For purposes of the rejection under 35 U.S.C. § 103(a), the claims include five groups 
of claims. Claims 7, 9, 11, 22, 26-27, and 32-40 are grouped together. Claims 18-20, 22, and 
31 are grouped together. Claim 15 comprises a grouping. Claims 29-30 are grouped 
together. Claim 41 comprises a grouping. 

VIII. ARGUMENT 
37 C.F.R. § 41.37(c)(l)(vii) 

A. Rejections Under 35 U.S.C. § 103(a) over Meltzer in view of Cronin and 
Heskett 

In the Final Office Action dated March 15, 2005, the Examiner rejected claims 7, 9, 
11, 15, 26-27, and 32-41 as being unpatentable over Meltzer in view of Cronin and Heskett. 
Because different claims include different features that Appellant believes are not taught by 
these references, Appellant will first discuss the individual references, then discuss the 
deficiencies in the references that apply to all claims, and finally discuss specific issues 
according to the claims as grouped above. 
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1 . Discussion about the prior art 
Melzter 

Meltzer teaches market makers using documents in a trading partner network. As 
shown in FIG. 15, Meltzer receives documents via a communication agent. The documents 
can be in any syntax. Meltzer converts the documents to XML, then uses an XML parser to 
verify that the documents are properly formatted in XML. Using the business interface 
definition compiler (BIDC), the documents are compiled into Java documents. The Java 
documents are then delivered to the enterprise solutions using the document service. 

Cronin and Heskett 

The Examiner relies on Cronin solely for the concept of stylesheets, and on Heskett 
for the concepts of using XML to exchange information housed in directories. {See Office 
Action dated April 12, 2005, page 3, f 6.) Appellant believes that neither Cronin nor Heskett 
teaches or suggests any other features of the claimed invention. 

Harrison 

Harrison teaches a system and method for Directory Enabled Networks/Lightweight 
Directory Access Protocol (DEN/LDAP) client database access with backoff capability. See 
column 3, lines 29-32. The LDAP server maintains a current tree of directory information 
{see Harrison, column 3, lines 33-35.). When a client wants to update policy configuration 
information, the tree is cloned or a new tree is built {see Harrison, column 3, lines 36-40.)s 
When the update is finished, clients are requested to access the new tree {see Harrison, 
column 3, lines 40-46.). 

The Examiner relies on Harrison for the concept that the distributed directory uses 
multiple processors and multiple memories, thereby partitioning the directory (i.e., 
distributing it). But the Examiner ignores key language in Harrison. Harrison describes the 
LDAP tree as "maintaining a current tree of directory information that is used by LDAP 
clients to retrieve configuration information" {see Harrison, column 3, lines 33-35). To make 
Harrison analogous to any element in the claimed invention, the LDAP clients would have to 
be analogous to the applications (as they are the elements in the claimed invention interacting 
with the directory). But this means that the LDAP clients would have to be able to access 
and use the LDAP directory. 

As described in this patent application at page 2, lines 15-16, some applications 
cannot access the distributed directory. It is for precisely these applications that the claimed 
invention operates. (If an application can successfully interact with the distributed directory, 
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it would not need to build its own copy of information about the distributed directory 
structure, and would not need to be notified about changes to the distributed directory.) Thus, 
Harrison builds a tree for precisely the applications for which the claimed invention is not 
needed. And the applications for which the claimed invention provides an advantage - those 
applications that cannot get information from the directory - are precisely those applications 
that could not be LDAP clients in Harrison. Accordingly, Harrison teaches away from the 
claimed invention, and cannot be combined with Meltzer, Cronin, and Heskett as the 
Examiner suggests. 

2. Issues applicable to all claims 

a. The references do not teach distributed directories 

In the Office Action dated April 12, 2005, the Examiner states that "Meltzer does not 
teach a distributed directory, [or] an event representing a change to the distributed directory . 
. . {see Office Action" dated April 12, 2005, page 3, 1f 6). The Examiner continues: "Heskett 
teaches using XML as a means to exchange information housed in directories .... Cronin 
teaches transforming the XML data to a predetermined format using a stylesheet . . . {see 
Id.). 

Appellant first notes that the Examiner has acknowledged that Meltzer does not teach 
two features of the claimed invention: a distributed directory, and events representing a 
change to the distributed directory {see Id.). But the Examiner does not suggest anywhere 
that these features are taught by Cronin or Heskett, instead pointing to other concepts in each 
reference. The Examiner leaves these specific features dangling, unaddressed. 

Reading between the lines of the Office Action, it appears that the Examiner is 
arguing that Heskett teaches a distributed directory. (The Examiner has admitted that Meltzer 
does not teach this concept {see Id.), and Appellant notes that Cronin does not even use the 
term "directory".) The Examiner has de facto admitted this in the Advisory Action dated July 
27, 2005, where the Examiner disagrees with the Applicant's argument that Heskett does not 
teach a distributed directory. But Heskett does not teach a distributed directory. Instead, 
Heskett describes a way to "use XML as a means to exchange information housed in 
directories". 

A distributed directory supports resources being spread across multiple computers in a 
network, where a client can access the resources without knowing their physical locations 
{see, e.g., specification, page 1, line 15 through page 2, line 2). Heskett does not teach or 
suggest this concept. At best, Heskett discusses directories in their general context. As a 
distributed directory is a distinguishable concept from a generic directory, the fact that 
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Heskett fails to teach or suggest distributed directories shows that the Examiner has failed to 
make a prima facie case for obviousness. 

It is also worth noting that Heskett describes the use of XML "as a means to exchange 
information" (emphasis added). In other words, any time any information is exchanged 
between directories, such exchange can be implemented using XML. For example, when a 
computer on the Internet accesses a web page on a server, the structure of the web page is 
transmitted from the server to the computer. The server stores the web page in a directory of 
some sort; and the computer uses folders (possibly temporary folders or caches) in its 
directory structure to store information received from the server to support the display of the 
web page on the monitor attached to the computer. So, there is an exchange of information 
between the directories: the server sends data from its directory to the directory on the 
computer. 

But this simple fact does not imply that the computer is all of a sudden part of a 
distributed directory with the server. No, the server and the computer remain independent 
directories: the user of the computer can only access public information from the server (such 
as the web page); and the directory of the computer (assuming it is properly configured) 
cannot be accessed at all by the server. Thus, the mere exchange of information does not 
teach or suggest the construction and/or use of a distributed directory. 

Appellant also notes that Heskett is a news article that is not even one page long. 
Heskett is not a patent reference, and does not attempt to call itself a patent. As such, Mr. 
Heskett did not provide enabling disclosures of any concepts at which he hinted. Thus, even 
if Heskett suggested the concept of a distributed directory (which Appellant disputes), 
Heskett does not enable the construction or use of a distributed directory. 

The Examiner has also raised considerable confusion as to whether distributed 
directories are considered new or not. In the Office Action dated April 12, 2005, the 
Examiner stated that distributed directories are a "new area" {see Office Action dated April 
12, 2005, page 4, ^ 7). But three months later, the Examiner stated that a distributed 
directory "is . . . very popular and well known in the technology" {see Advisory Action dated 
July 27, 2005, page 2). 

Either distributed directories are new or not. And even if distributed directories are 
known in the art, that does not automatically mean that any method that could be applied to 
an ordinary directory can obviously be applied to a distributed directory. It is well 
recognized that an inventor can take a known idea and apply it to a new technology and 
patent that combination. Thus, even if distributed directories are known in the art, the 
Examiner still bears the burden of establishing that it would have been obvious to modify the 
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references to apply them to a distributed directory. The mere fact that Heskett mentions 
directories does not mean that Heskett's suggestion of using XML to exchange information 
between directories is immediately applicable to distributed directories. 

In addition, the Examiner's statement that "if XML could be used between different 
directories, it could also be used in a directory and its replicas" {see Advisory Action dated 
July 27, 2005, page 2) shows a basic misunderstanding about the claimed subject matter. 
First, if "distributed directory" meant "a directory and its replicas", the Examiner's argument 
might have some merit. But as discussed above, a distributed directory enables clients to 
access resources without knowing their physical locations. If "distributed directory" were to 
be interpreted to mean a directory that is completely replicated, a client would know the 
location of any desired resource: any replica of the directory would have a copy of the 
resource. The ordinary interpretation of the term "distributed directory", therefore, would not 
be "a directory that is replicated"; the ordinary interpretation would be "a directory that is 
distributed (i.e., portions of the directory are located in different places)". For example, 
consider claim 18, which describes two processors, each with connected memories, and 
portions of the distributed directory are stored in the memories. The claim does not state that 
each memory contains a complete copy of the directory. 

In making his arguments about what would be obvious over Heskett, the Examiner is 
assuming that a person skilled in the art would be familiar with regular directories and with 
XML. These assumptions are not necessarily warranted. Appellant posits that a person 
skilled in the art would understand that distributed directories are different from regular 
directories. Such a person would understand that a solution applicable to regular directories 
might not apply to distributed directories. In addition, a person skilled in the art of 
distributed directories at the time of the invention might not have been familiar with XML. 
Heskett is limited to regular directories, and does not show what a person skilled in the art of 
distributed directories might have known. 

The second problem with the Examiner's misunderstanding about the claimed subject 
matter lies in the fact that the events are not being exchanged between "a directory and its 
replicas". Events that originate within the distributed directory are transformed and 
transmitted to applications. And events that originate with applications are transmitted to the 
distributed directory. Applications are not replicas of the distributed directory. Therefore, 
for the Examiner to argue that it would be obvious to use XML to exchange information 
between a directory and its replicas is irrelevant with respect to the claimed invention. 

Appellant notes that applications might store information about the directory. But 
that is not the same thing as storing a replica of the directory. Appellant would like to point 
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to page 2, lines 16-18 of the specification, which describes one of the problems the claimed 
invention attempts to address as applications storing information about resources. Note that 
the specification does not say that the application is storing a copy of the resource; the 
application stores the information about the resource. 

b. The references do not teach events representing a change to the distributed 
directory 

As with distributed directories, the Examiner appears to be relying on Heskett to teach 
the concept of events that represent changes to the distributed directory. The Examiner has 
admitted that Meltzer does not teach this concept, and, as argued above, Cronin does not 
mention directories at all, let alone distributed directories or events representing changes to 
distributed directories. The Examiner also states that "a directory retrieving] requested data 
is one type of event in the directory" {see Office Action dated April 12, 2005, page 3, If 6). 

First, Appellant points out that if Heskett fails to teach or suggest a distributed 
directory (as argued above), Heskett cannot teach events in the distributed directory. But 
more to the point, the event in the claimed invention is described as an event representing a 
change to the distributed directory. That Heskett might teach a directory retrieving requested 
data, and that such a retrieval might be an event in the directory, does not demonstrate that 
Heskett teaches an event representing a change to the distributed directory. Accordingly, the 
Examiner has failed to show that Heskett teaches the specific feature for which the Examiner 
cites to Heskett, meaning that the Examiner has failed to make a prima facie case for 
obviousness. 

In the Advisory Action dated July 27, 2005, the Examiner also states that "Heskett 
teaches using XML to exchange data between directories in the network" {see Advisory 
Action dated July 27, 2005, page 2). Appellant asserts that "exchanging] information 
housed in directories" is not the same as an event representing a change to the distributed 
directory. There are many different reasons why information might be exchanged between 
directories: see above regarding the example of a computer downloading a web page from a 
server. While a change to a distributed directory might be a type of information exchanged 
using XML, Heskett still only teaches the generic (and non-enabling) description of using 
XML to exchange information, and not the more specific concept of events representing a 
change to the distributed directory. Further as discussed above, Heskett is not an enabling 
reference, providing only a passing suggestion of how XML might be used to exchange 
information. As Heskett is not specific, and because Heskett is not enabling, Heskett does 
not teach events representing changes to a distributed directory. 
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3. The claim groups 

a. Claims 7, 9, 11, 22, 26-27, and 32-40 are not obvious over Meltzer in view of 
Cronin and Heskett 

As discussed above, the Examiner has admitted that Meltzer teaches neither a 
distributed directory nor events representing a change in the distributed directory. The only 
possible reference the Examiner could be relying on for these features is Heskett. And, as 
argued above, Heskett does not teach a distributed directory or events representing changes to 
the distributed directory. As claims 7, 9, 11, 22, 26-27, and 32-40 recite such features as a 
"distributed directory" and an "event representing a change to the distributed directory" 
(using as exemplary language from claim 7), these features are not taught by any of the cited 
references. Accordingly, claims 7, 9, 11, 22, 26-27, and 32-40 are patentable under 35 
U.S.C. § 103(a) over Meltzer in view of Cronin and Heskett, and are therefore allowable. 

b. Claims 18-20, 22, and 31 are not obvious over Meltzer in view of Cronin, 
Heskett, and Harrison 

As discussed above, the Examiner has admitted that Meltzer teaches neither a 
distributed directory nor events representing a change in the distributed directory. The only 
possible reference the Examiner could be relying on for these features is Heskett. And, as 
argued above, Heskett does not teach a distributed directory or events representing changes to 
the distributed directory. Finally, as argued above, Harrison teaches away from the claimed 
invention, and therefore cannot be combined with Meltzer, Cronin, and Heskett. As claims 
18-20, 22, and 31 describe as features a "distributed directory" and a "directory event 
representing a change to the distributed directory" (using as exemplary language from claim 
18), these features are not taught by any of the cited references. Accordingly, claims 18-20, 
22, and 31 are patentable under 35 U.S.C. § 103(a) over Meltzer in view of Cronin, Heskett, 
and Harrison, and are therefore allowable. 

c. Claim 15 is not obvious over Meltzer in view of Cronin and Heskett 

Claim 15 is directed toward a software program for facilitating the use of a distributed 
directory running in a computer network, the program comprising instructions for: receiving 
a first event from a first application in a first native application format, the first event 
representing a first change to the distributed directory; converting the first event into markup 
language data; transforming the first event to a predetermined format by a transformation 
processor using a transformation profile, the predetermined format being responsive to the 
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distributed directory, the transformation profile including formatting instructions for 
transforming the markup language data to the predetermined format, the distributed directory 
including a reference to at least one resource on one of at least two computers on the 
computer network; transmitting the transformed first event to the distributed directory; 
receiving a second event from a second application in a second native application format, the 
second event representing a second change to the distributed directory; converting the second 
event into markup language data; transforming the second event to the predetermined format 
by the transformation processor using the transformation profile; and transmitting the 
transformed second event to the distributed directory. 

First, claim 1 5 includes the features of a distributed directory and an event 
representing a change in the distributed directory. As discussed above, the Examiner has 
admitted that Meltzer teaches neither a distributed directory nor events representing a change 
in the distributed directory. The only possible reference the Examiner could be relying on for 
these features is Heskett. And, as argued above, Heskett does not teach a distributed 
directory or events representing changes to the distributed directory. 

Second, in contrast to claims 7, 18, 32, and 40, where the event is received from the 
distributed directory, claim 15 describes the events (plural) as being received from the 
applications (plural). In addition, the events are each received in native application formats, 
converted into markup language data, transformed into a predetermined format, and 
transmitted to the distributed directory. This is a flow of direction opposite to that of claims 
7, 18, 32, and 40. Thus, it becomes important whether Meltzer teaches a unidirectional 
dataflow or a bidirectional dataflow. 

In arguing that the handling of events is obvious in light of the references, the 
Examiner has relied on Meltzer in its teaching about processing documents. To the extent 
that Meltzer shows data flow, that data flow is unidirectional. FIG. 15 of Meltzer shows the 
components of the market maker node, which the Examiner has consistently argued is 
responsible for the data flow that renders most of the claimed invention obvious. FIG. 15 is 
explicit in showing data flowing in only one direction: from left to right within the drawing. 
There is no data shown flowing in the reverse direction (from right to left), and the 
accompanying description also fails to mention data flowing in the reverse direction. Thus, 
Meltzer can teach data flowing in only one direction; the Examiner cannot arbitrarily switch 
the direction in which data flows to suit the rejection of the claims. 

It would be inappropriate for the Examiner to argue that data coming from Enterprise 
Solution 1505 of Meltzer could be received by Communication Agent 1500 of Meltzer. The 
reason for this is that data coming into the market maker node is received using protocols, 
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such as HTTP, FTP, SMTP, etc. But data sent to Enterprise Solution 1505 is sent via APIs, 
CORBA, COM, etc. The protocols used by Communication Agent 1500 are not 
interchangeable with the interfaces used by Enterprise Solution 1505: the ways in which 
protocols and interfaces work are completely different. Thus, the fact that the arrows in FIG. 
15 move data in one direction only is not an accident or an error by Meltzer: it is a 
consequence of the operation of the market maker node. If the Examiner is going to maintain 
the rejections of the claims as obvious over the operation of the market maker node of 
Meltzer, the Examiner needs to decide which direction of data flow in the claimed invention 
is to be analogized to the data flow of FIG. 15. (This is independent of the problem that none 
of the references teach a distributed directory.) 

Further, Meltzer describes the market maker node as receiving data from nodes (see 
box 1200 of FIG. 12 of Meltzer). Such nodes would be applications of some sort; they would 
not be a directory. Thus, there is no suggestion to modify Meltzer to use a directory, let alone 
a distributed directory, as either end of FIG. 15 of Meltzer. It is therefore inappropriate to 
analogize the distributed directory of the claims to either the source from which 
Communication Agent 1500 receives data or Enterprise Solution 1505. 

Claim 15 recites as features a "distributed directory" and "event[s] representing 
change[s] to the distributed directory". These features are not taught by any of the cited 
references. Further, if the Examiner maintains her analogy that FIG. 15 of Meltzer renders 
obvious the direction of data flow described in claims 7, 18, 32, and 40, then the reverse 
direction of data flow as described in claim 15 is not taught or suggested by any of the cited 
references. Accordingly, claim 15 is patentable under 35 U.S.C. § 103(a) over Meltzer in 
view of Cronin and Heskett, and is therefore allowable. 

d. Claims 29-30 are not obvious over Meltzer in view of Cronin, Heskett, and 
Harrison 

As discussed above, the Examiner has admitted that Meltzer teaches neither a 
distributed directory nor events representing a change in the distributed directory. The only 
possible reference the Examiner could be relying on for these features is Heskett. But as 
argued above, Heskett does not teach a distributed directory or events representing changes to 
the distributed directory. Further, as argued above, Harrison teaches away from the claimed 
invention, and therefore cannot be combined with Meltzer, Cronin, and Heskett. 

In addition, claims 29-30 depend from claim 18, which describes software for 
detecting a directory event in the distributed directory, software for transforming the 
directory event into predetermined formats, and software for providing the transformed event 
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to applications. Claims 29-30 further add software for detecting events in the applications, 
software for transforming the events to a directory predetermined format, and software for 
providing the transformed events to the distributed directory. Thus, claims 29-30 explicitly 
describe a bi-directional data flow: events from the distributed directory are provided to the 
applications, and events from the applications are provided to the distributed directory. As 
argued above, Meltzer teaches only a unidirectional data flow. And regardless of which 
direction might be selected for analogy to Meltzer, Meltzer still teaches a unidirectional data 
flow. Thus, Meltzer cannot make obvious claims directed toward bidirectional dataflow. 

As claims 29-30 describe as features a "distributed directory" and "application 
event [s]" and describes bidirectional data flow, these features are not taught by any of the 
cited references. Accordingly, claims 29-30 are patentable under 35 U.S.C. § 103(a) over 
Meltzer in view of Cronin, Heskett, and Harrison, and are therefore allowable. 

e. Claim 41 is not obvious over Meltzer in view of Cronin and Heskett 

As discussed above, the Examiner has admitted that Meltzer teaches neither a 
distributed directory nor events representing a change in the distributed directory. The only 
possible reference the Examiner could be relying on for these features is Heskett. But as 
argued above, Heskett does not teach a distributed directory or events representing changes to 
the distributed directory. 

In addition, claim 41 depends from claim 40, which describes a generator to receive a 
directory event from the distributed directory and to generate a generic data for the directory 
event, transformation profiles defining predetermined formats for applications, a 
transformation processor to transform the directory event into data for the applications, and a 
transmitter to transmit the application data to the applications. Claim 41 further adds a 
second generator to receive an application event from the first application and to generate a 
second generic data for the application event, the transformation processor operative to 
transform the second generic data for the application event into a directory data, and a 
receiver to receive the directory data in the directory. Thus, claim 41 explicitly describes a 
bi-directional data flow: events from the distributed directory are provided to the 
applications, and events from the applications are provided to the distributed directory. As 
argued above, Meltzer teaches only a unidirectional data flow. And regardless of which 
direction might be selected for analogy to Meltzer, Meltzer still teaches a unidirectional data 
flow. Thus, Meltzer cannot make obvious claims directed toward bidirectional dataflow. 

Claim 41 recites as features a "distributed directory" and "application event[s]" and 
describes bidirectional data flow. These features are not taught by any of the cited 
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references. Accordingly, claim 41 is patentable under 35 U.S.C. § 103(a) over Meltzer in 
view of Cronin and Heskett, and is therefore allowable. 
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CONCLUSION 



For the foregoing reasons, the Examiner has failed to make a prima facie case of 
obviousness, Meltzer, Cronin, Heskett, and Harrison fail to teach or suggest all of the features 
of the claimed invention. And Harrison teaches away from the claimed invention and so 
cannot be combined with Meltzer, Cronin, and Heskett. Appellant requests that the Board 
reverse the Examiner's rejections of Appellant's claims under 35 U.S.C. § 103(a). 

Customer No. 45842 Respectfully submitted, 
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APPENDIX 
37 C.F.R. § 41.37(c)(l)(viii) 

The text of the claims on appeal (7, 9, 11, 15, 18-20, 22, 26-27, and 29-41) is: 

1. (Canceled) 

2. (Canceled) 

3. (Canceled) 

4. (Canceled) 

5. (Canceled) 

6. (Canceled) 

7. (Previously Presented) A software program for facilitating the use of a 
distributed directory running in a computer network, the program comprising being stored on 
a recordable medium and including instructions for: 

receiving an event from the distributed directory into an XML generator, the 
distributed directory including a reference to at least one resource on one of at least two 
computers on the computer network, the event representing a change to the distributed 
directory; 

converting the event into XML data representing the event; 

transforming the XML data representing the event to a first predetermined format by a 
transformation processor using a first stylesheet, the first predetermined format being 
responsive to a first application running in the computer network; 

transmitting the transformed XML data representing the event to the first application; 

transforming the XML data representing the event to a second predetermined format 
by the transformation processor using a second stylesheet, the second predetermined format 
being responsive to a second application running in the computer network; and 

transmitting the transformed XML data representing the event to the second 
application. 

8. (Canceled) 
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9. (Previously Presented) The software program of claim 7 further 
comprising instructions for: 

receiving updates to the first stylesheet responsive to any changes in either the 
distributed directory or the first application. 

10. (Canceled) 

1 1 . (Previously Presented) The software program of claim 7 further 
comprising instructions for: 

detecting the event through notification from an event handler of the distributed 
directory. 

12. (Canceled) 

13. (Canceled) 

14. (Canceled) 

15. (Previously Presented) A software program for facilitating the use of a 
distributed directory running in a computer network, the program comprising instructions for: 

receiving a first event from a first application in a first native application format, the 
first event representing a first change to the distributed directory; 
converting the first event into markup language data; 

transforming the first event to a predetermined format by a transformation processor 
using a transformation profile, the predetermined format being responsive to the distributed 
directory, the transformation profile including formatting instructions for transforming the 
markup language data to the predetermined format, the distributed directory including a 
reference to at least one resource on orie of at least two computers on the computer network; 

transmitting the transformed first event to the distributed directory; 

receiving a second event from a second application in a second native application 
format, the second event representing a second change to the distributed directory; 

converting the second event into markup language data; 

transforming the second event to the predetermined format by the transformation 
processor using the transformation profile; and 

transmitting the transformed second event to the distributed directory. 
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16. (Canceled) 



17. (Canceled) 

18. (Previously Presented) A distributed computer system comprising: 
a first processor connected to a network for executing computer code; 

a second processor connected to the network for executing computer code; 

a first memory connected to the first processor; 

a second memory connected to the second processor; 

a distributed directory, wherein first and second portions of the distributed directory 
are stored in the first memory and the second memory, respectively; 

a first application, a portion of which being stored in one of the first memory and the 
second memory; 

a second application, a portion of which being stored in one of the first memory and 
the second memory; 

a first transformation profile defining a first predetermined format for use by the first 
application; 

a second transformation profile defining a second predetermined format for use by the 
second application; 

software for detecting a directory event in the distributed directory, the directory 
event representing a change to the distributed directory; 

software for transforming the directory event to the first predetermined format by 
using a generic transformation tool and the first transformation profile; 

software for transforming the directory event to the second predetermined format by 
using the generic transformation tool and the second transformation profile; 

software for providing to the first application the directory event transformed to the 
first predetermined format; and 

software for providing to the second application the directory event transformed to the 
second predetermined format. 

19. (Previously Presented) The system of claim 18 further comprising: 
software for converting the directory event to a generic data description before 

transforming the directory event. 
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20. (Previously Presented) The system of claim 18 further comprising: 

an application shim for the first application to receive the transformed directory event 
and provide the directory event to the first application by using a first native application 
program interface for the first application. 

21. (Canceled) 

22. (Previously Presented) The system of claim 18 wherein the generic 
transformation tool utilizes a markup language and the software for transforming the 
directory event utilizes a transformation processor. 

23. (Canceled) 

24. (Canceled) 

25. (Canceled) 

26. (Previously Presented) The software program of claim 7 wherein: 
transmitting the transformed XML data representing the event to the first application 

includes transmitting the transformed XML data representing the event to the first application 
through a first application shim to provide the transformed XML data representing the second 
event to the first application by using a first native application program interface for the first 
application; and 

transmitting the transformed XML data representing the event to the second 
application includes transmitting the transformed XML data representing the event to the 
second application through a second application shim to provide the transformed XML data 
representing the event to the second application by using a second native application program 
interface for the second application. 

27. (Previously Presented) The software program of claim 7 wherein the 
first predetermined format and the second predetermined format are the same predetermined 
format. 

28. (Canceled) 
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29. (Previously Presented) The system of claim 18 further comprising: 

a directory transformation profile defining a directory predetermined format for use 
by the distributed directory; 

software for detecting an application event in the first application; 

software for transforming the application event to the directory predetermined format 
by using the generic transformation tool and the directory transformation profile; and 

software for providing the transformed application event to the distributed directory. 

30. (Previously Presented) The system of claim 29 further comprising: 
software for detecting a second application event in the second application; 
software for transforming the second application event to the directory predetermined 

format by using the generic transformation tool and the directory transformation profile; and 

software for providing the transformed second application event to the distributed 
directory. 

3 1 . (Previously Presented) The system of claim 20 further comprising: 
a second application shim for the second application to receive the transformed 

directory event and provide the directory event to the second application by using a second 
native application program interface for the second application. 

32. (Previously Presented) A method for interfacing with a distributed 
directory in a computing system, comprising: 

providing a first transformation profile defining a first predetermined format for use 
by a first application; 

providing a second transformation profile defining a second predetermined format for 
use by a second application; 

detecting an event in the distributed directory, the distributed directory including a 
reference to at least one resource on one of at least two computers on the computer network, 
the event representing a change to the distributed directory; 

transforming the event to the first predetermined format by using a transformation 
tool and the first transformation profile; 

transforming the event to the second predetermined format by using the 
transformation tool and the second transformation profile; 

providing to the first application the event transformed to the first predetermined 
format; and 
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providing to the second application the event transformed to the second 
predetermined format. 

33. (Previously Presented) The method of claim 32 further comprising the 

step of: 

converting the event to a generic data description before transforming the event to the 
first predetermined format and the second predetermined format. 

34. (Previously Presented) The method of claim 32 further comprising the 

step of: 

providing an application shim for the first application to receive the event transformed 
to the first predetermined format and to provide the event to the first application by using a 
native application program interface for the first application. 

3 5 . (Previously Presented) The method of claim 34 further comprising the 

step of: 

updating the application shim and the first transformation profile responsive to 
changes in the first application. 

36. (Previously Presented) The method of claim 34 further comprising the 

step of: 

providing a second application shim for the second application to receive the event 
transformed to the second predetermined format and to provide the event to the second 
application by using a second native application program interface for the second application. 

37. (Previously Presented) The method of claim 36 further comprising the 

step of: 

updating the second application shim and the second transformation profile 
responsive to changes in the second application. 

38. (Previously Presented) The method of claim 32 wherein the 
transformation profile includes a stylesheet. 

39. (Previously Presented) The method of claim 32 wherein the 
transformation profile is stored in the distributed directory. 
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40. (Previously Presented) A driver infrastructure for interfacing a 
distributed directory and applications comprising: 

a generator to receive a directory event from the distributed directory and to generate 
a generic data for the directory event, the distributed directory including a reference to at least 
one resource on one of at least two computers on a computer network, the directory event 
representing a change to the distributed directory; 

a first transformation profile defining a first predetermined format for use by a first 
application; 

a second transformation profile defining a second predetermined format for use by a 
second application; 

a transformation processor to transform the generic data for the directory event into a 
first application data for the first application using the first transformation profile and to 
transform the generic data for the directory event into a second application data for the 
second application using the second transformation profile; and 

a transmitter to transmit the first application data to the first application and to 
transmit the second application data to the second application. 

41 . (Previously Presented) A driver infrastructure according to claim 40 
wherein: 

the driver infrastructure further comprises a second generator to receive an application 
event from the first application and to generate a second generic data for the application 
event; 

the transformation processor is operative to transform the second generic data for the 
application event into a directory data; and 

the driver infrastructure further comprises a receiver to receive the directory data in 
the directory. 
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